Multicasting enables a sending source to broadcast the same data packets over a network to each terminal of a designated group of destination terminals in one sending. In the context of the Internet in particular, multicasting is covered by a specific transmission protocol which was produced for terminals connected by cable broadcast local area networks, such as Ethernet networks, which support listening between terminals. The protocol exploits this listening facility to lighten the traffic of acknowledgment messages sent by the destination terminals, as explained below. The object of the invention is to make this facility available to networks of satellite or like terminals that do not support listening between terminals.
The multicast services on offer are at present in their early days, as optimizing the Internet bandwidth has been considered to be of secondary importance compared to growing the network. The galloping increase in the bandwidth required for Internet services, because of the enthusiasm of the public and the rapid growth of the services on offer, is beginning to show up the inevitable limitations of multicast broadcasting.
Satellite systems have the natural advantage of offering point-to-multipoint services (which explains their success in direct video broadcasting by satellite (DVB-S) services, and they are therefore very well positioned for the new multicast market. The present growth of and interest in this market are comparable to the penetration of the web a few years ago. Multicast client applications are numerous:
TV broadcasting,
real-time broadcasting of stock market prices,
videoconferences,
on-line business (bids),
stock distribution,
etc.
Multicasting is already implemented in Internet cable networks, for which it is standardized by Requests For Comments RFC 1112 and RFC 2236 of the Internet Engineering Task Force (IETF), respectively representing versions 1 and 2 of the Internet Group Management Protocol (IGMP).
Under this protocol, the receiver terminals do not have only a passive role, but must send specific messages and listen, with a very short time-delay, to the transmissions of other terminals connected to the same transmission medium.
FIG. 1 is a diagrammatic representation of the multicast data communication principle of the IETF's IGMP on a cable broadcast network such as an Ethernet network.
Multicast data is sent in the form of successive packets ( . . . , DPm-2, DPm-1, DPm, . . . ) over the Internet 2 and in accordance with the IGMP from a source 4 to a multicast edge router 6. The router is responsible for forwarding multicast data packets received from the Internet 2 to the cable subnetwork 8 within which it is responsible for broadcasting. The subnetwork 8, which is an Ethernet network, for example, connects a number r of terminals Tl-Tr to support:
quasi-simultaneous reception by each terminal that is a member of a multicast group of the same multicast data packet DPi forwarded by the edge router 6,
sending of messages from any terminal to the edge router 6,
listening by any terminal to messages sent to the router by any other terminal, and
exchange of data between the terminals.
The following description refers to two ends of the multicast transmission medium:
the multicast data sending end E, which is generally the end at which the router 6 or a medium access gateway is located, and
the multicast data receiving end R, which is generally the end at which the inputs of the terminals Tl-Tn are located.
For a given multicast session, the router 6 identifies the group G of participating terminals to which the data packets must be sent. The group G of participating terminals is identified by an address in each packet DP received by the router 6. The group G may constitute a varied and changing number of terminals, from one terminal to all of the terminals served by the router. In the FIG. 1 example, the group G comprises a number n of terminals Tl-Tn shown receiving the same data packet DPi. Note that a plurality of different multicast groups can be served by the same router 6 and that some terminals can participate in more than one group at a time. Similarly, the multicast source 4 can send data packets to a plurality of different edge routers.
The main problem with the multicast edge router 6 is determining whether it must forward the packets received or not. It is therefore preoccupied with finding out if there is at least one participating terminal in the group identified by the address of the multicast packet that it has just received from the Internet 2.
The IGMP, as defined by the IETF in RFC 1112, includes a mechanism for maintaining groups that enables a local multicast router to find out if there is still at least one member terminal of a given multicast group in the subnetwork 8. This enables it to decide whether it should still route the traffic of that group to the network or stop doing so.
This mechanism simply consists in the router 6 periodically sending a membership query defined by the IGMP. This query is picked up by all the terminals Tl-Tr connected to the local area network 8. A terminal that wishes to remain or to become a member of a group G must respond to the router 6 with a membership report message to indicate to the router that it is still interested in the traffic of that group.
According to the standard, the router has no need of a comprehensive list of all the member terminals, and only needs to know whether there is at least one member terminal or none at all. Consequently, there would seem to be no point in all the member terminals responding to the query, disturbing the other participants to decode their own response, and creating an overload on the network.
Because a single response is sufficient to provide the router 6 with the necessary information, the standard specifies that, on receiving a query, each terminal must start a random time-delay before responding. During this time-delay, each terminal listens to the line to intercept a response coming from any other terminal. If no response has been picked up on the line when the time-delay of one terminal expires, then only that terminal sends its response, which is picked up by the other terminals, which react by interrupting their time-delay without sending their response. This ensures that only one response is returned for each query sent by the edge router 6, regardless of the composition of the group of terminals, which avoids the overload problem.
Clearly the advantage at which the RFC 1112 standard is aimed cannot be obtained if the subnetwork (such as a network of satellite or like terminals) does not enable a terminal to intercept responses sent to the router 6 by another terminal.
The organization of this kind of subnetwork and its operation in multicast mode are described with reference to FIG. 2 in the context of a network of satellite terminals. The communication system is similar to that of FIG. 1, except that the subnetwork 80 includes satellite communication channels.
The example is based on an A 9780 NG satellite access network architecture. The multicast data source 4 is connected to an edge router 6 conforming to the IGMP protocol via the Internet 2, but it is to be understood that the source can be connected to the router by any other communication channel.
The router 6 communicates with the satellite terminals STl-STr via a ground station 10, known as a gateway, comprising a transceiver associated with a satellite antenna, the gateway and the router being connected by a bi-directional transmission cable 9 or the like. The gateway 10 sets up a communication link to a geosynchronous telecommunication satellite 12 which serves as a relay station for all the satellite terminals STl-STr. Each satellite terminal ST includes a parabolic antenna and radio-frequency send-receive circuits 14 connected to a personal computer PC or other communication unit via an IGMP host 15. The router 6 can therefore send multicast data packets to the satellite terminals and receive messages sent by them.
For each local area network 80, characterized by its radio carrier frequency, the satellite 12 provides:
a go link from a gateway 10 to the satellite terminals ST listening to this radio carrier frequency (f1), and
a return link on another radio carrier frequency (f2) associated with the go link, for conveying messages from the satellite terminals ST to the gateway 10.
Each satellite terminal can receive (or to be more precise, listen to) all the messages on the go link, including those addressed to other terminals, but only the gateway 10 can receive messages from a terminal. This is because the channels usually employ a receive frequency f1 common to all the terminals that is necessarily different from their transmit frequency f2, which may or may not be common to all the terminals, and so are not able to listen to the transmissions of other terminals. Note that the idea of adding to the satellite terminal means for listening to the second frequency can be realized only by providing relatively costly hardware, including a second receiver system and a duplexer.
Accordingly, only the gateway 10 can receive membership report responses from the satellite terminals ST, whereas all the terminals receive the membership query sent once only by the gateway 10 and carrying either the multicast address of all the terminals or the multicast address of the group for which it sends the membership query message.
What is more, geosynchronous satellite transmission systems induce a minimum time-delay of approximately 270 milliseconds (ms) between sending by the source (edge router 6) and reception by the destination (terminal ST), which makes the IETF solution even less applicable.
For these reasons, the standard mechanism used for cable subnetworks, based on inter-terminal surveillance and using time-delays to interrupt the sending of responses by the terminals, unfortunately will not work on a satellite or like link which connects the terminals to a central IGMP router (or function), whether it is behind a gateway or in a satellite Network Control Center (NCC). Applying the RFC 1112 standard in the conventional way, the return satellite channels are periodically overloaded by this response traffic to the queries sent (the RFC 1112 standard prevents this in networks supporting broadcast transmission).
To give a more concrete example of the orders of magnitude involved, and considering a system in which 5000 multicast groups use the satellite subnetwork 80 and each group is picked up by 2000 member terminals, in each interrogation period (i.e. on average every minute, according to the average value proposed in the RFC 1112 standard), a response traffic volume of 5000×2000 packets is generated. Taking the somewhat favorable situation of a radio packet having a size of 55 bytes, this induces a mean bit rate—and thus a bandwidth—of approximately 75 Mbit/s.
Moreover, this traffic is not uniformly distributed over the whole of the one minute period. According to IGMP version 2, the router 6 can request a response from the terminals ST within a maximum time-delay of 25.6 seconds. If a lower value is chosen, for example 5 seconds, the traffic is concentrated in this shorter period of 5 seconds.
Now, one fundamental characteristic of radio transmission systems is the limited band of frequencies that can be used for each system. The transmission capacity of these systems is fundamentally related to the allocated frequency band. Optimizing transmission capacity by minimizing the number, size or duration of messages is a constant preoccupation of radio transmission system designers.